∂02-OCT-75  1056	E,ALS
To:   ME
RF reports a bug in F which I do not believe was there before one of your fixes.
It is not very serious but probably should be fixed. Are you responsible?
∂02-OCT-75  0804	E,ALS
What few changes that I have made are all debugged. I think I have a fix to the
period-at-the end- of -a -line bug but I will put this in on a separate copy of
E first. Let me know when you come in just in case I decide to put this in the
CSP,SYS copy before you show up.

∂29-SEP-75  1118		E,ALS
 Could you come in and demonstrate your trouble with PARENs
␈ CC: MFB

∂26-SEP-75  1407		E,ALS
 I have looked into the problems of using ETV and TVE at other locations and the
 main road block is common to both in that they both require a system line-editor
 and one that understands the conventions used in the editor. So I do not think
 that it would help you much to get the other source. One advantage is that it
 is in SAIL and therefore easier to read. The source file for the SAIL program
 is not currently up on our system but it is still available on some back-up
 tapes. As reguards the documentation of ETV- I have been adding to the comments
 as time goes on and they are not nearly as deficient as they once were. Do you
 have a recient copy?
␈ CC: %CMU-10A HEDRICK;%CMU-10B HEDRICK

∂25-SEP-75  1407		E,ALS
 The mystery is solved or maybe deepened as to the absence of INVALID DIRECTORY
 reports on TELLME. They have been being written under other names and with
 all sorts of queer protection bits. I have consolidated these in one file,
 spooled it and then deleted some 15 or 20 of these trick files. Apparently
 When people tried to follow my instructions about sending several Tellme
 roports they started the following ones before the first one had cleared. At
 least there are several with almost the same time and on different files.
 The situation is sufficiently complicated that I decided to start Tellme.001
 over and to watch it carefully for a day or so.
␈ CC: me

∂23-SEP-75  1312		E,ALS
 See E.ALS[UP,DOC] page 22.
␈ CC: BPM

∂22-SEP-75  2242		E,ALS
 What do you mean? If it is the fact that I am running HOT then maybe it
 should be taken off the system. This is one of the few times I have
 run this program but I wanted to see if there was any late news on the latest shooting.
  There seems to be none so I am going to bed.
␈ CC: reg

∂19-SEP-75  1128		E,ALS
 Where do I find the SAI copy of the old TVE?
␈ CC: REG

∂12-SEP-75  0849		E,ALS
 ***The printer needs fixing.****
␈ CC: TED

∂11-SEP-75  1033		E,ALS
 Could you drop in some time to discuss the common bug which you seem to
 encounter more than anyone else. the NEXT DIRECTORY POINTER INVALID one.
 There must be something peculiar either about your file or your operating
 procedure.	ALS
␈ CC: GHB

∂10-SEP-75  1352		E,ALS
 A technique to get around your trouble until I do aa proper fix. Assume that
 you have given a αβ( then a β something and now want to find the matching
 ) for the initial (  then if you give 2 αβ↔ 's in a row you will land where
 you were on the first ( and the α) command will now work OK.
␈ CC: MFB

∂10-SEP-75  0834		E,ALS
 It seems that you gave a <control>+<control>5<control>F command. Why the + sign?
 This should not cause any trouble and in fact I have tried to repeat your trouble
 without success but I wonder why you did this. Is it possible that you did not keep
 the control key down during the entire command? This is the first bug of this sort
 to be reported for some time.
␈ CC: mjc

∂05-SEP-75  0952		E,ALS
 TELLME fixes are up.
 CC: ME

∂04-SEP-75  0941		E,ALS
 I fixed the DSTRL bug by surpressing setting of the indicator when T is out of
 range. This is a hack however. The right thing to do is it see that DSTRL is not
 called at all unless it is really needed. It is now called more than once in a
 number of different situations, the most flagrant being the case you found where
 BOTWIN has been flagged as needing resetting but has not yet been reset to the
 correct value. I fixed E but I have not yet put it up on the system because I
 am looking into the matter to see how to do a better job. The difficulty in doing
 this seems to be that there are cases where one does not yet know whether a second
 setting will be invoked or not. It may be that a negαtive value in BOTWIN is a
 sure indicator but I am not yet sure.
 CC: me

∂03-SEP-75  1009		E,ALS
 I accumulated some statistics on TELLME reports since AUG 24th.
 
 DIRCHK+12  CAME A,1(E) occurred 27 times (directory point invalid)
 RDLONG+3   JRST RDLIN+2          4 TIMES   (TOO LONG LINES)
 then 1 each of the following
 WRDONE+4  CAME T,CHARS
 FUCHK+2   CAIL TT,C
 FSGIVE+1  CAME A,FSMIN
 WROM+16   CAME C,1(T)
 WRPM+7    CAIE T,(C)
  There were also some cases where people called TELLME directly.
 It looks like the invalid directory bug is the only serious one showing.  The
 other cases can be accounted for as due to real errors in the text or to a
 variety of causes.
 i
 CC: ME

∂03-SEP-75  0835		E,ALS
 The INDE5+1 bug does seem to have been around foe some time, perhaps from the
 time I wrote this section. The interesting thing is how it had excaped detection
 until now. Thanks for finding it.
 CC: ME

∂24-AUG-75  0915		E,ALS
 KRD reports trouble with XCENTER which has never happened before. Have you done
 anything to cause this? TELLME reports a FF out of place but his message to me
 said nothing about this.
 CC: me

∂22-AUG-75  0929		E,ALS
 ALS here. Yes if you can establish the connection.
 CC: %CMU-10A HEDRICKS

∂22-AUG-75  0928		E,ALS AT TTY32   0928
 ALS here. YES.
 CC: %CMU-10B hedricks

∂22-AUG-75  0927		E,ALS AT TTY32   0927
 ALS here. The answer is yes.
 CC: %CMU-10A HEDRICKS

∂22-AUG-75  0812		E,ALS
 Sorry to pester you with questions to which I could find the answers but I had
 just listed them and the machine was due to go down and I was going out and would
 not be back so I sent them on to you without further checking.
 CC: ME

∂21-AUG-75  1036		E,ALS
 This is a repeat message.
 You could probably adapt the older TVEDIT to your system fairly easily as several
 others have done. Our ETV, by now contains quite a few features that the TVEDIT
 did not contain but so far as I know it has not been adapted by others for systems
 with different display capabilities. I will be glad to talk with you about this.
 I will be away all next week however.
 CC: %CMU-10B HEDRICK

∂21-AUG-75  1004		E,ALS
 You could probably adapt the older TVEDIT to your system fairly easily as
 several others have done. ETV now contains quite a few additional features that
 were not in TVEDIT and so far as I know noone has tried to adapt it to another
 system with different display capabilities. I would be glad to talk with you
 about the problems if you can arrange a convienent time. I will be away all next
 week however.πZiπZu
 CC: %CMUA HEDRICK

∂21-AUG-75  0938		E,ALS
 Another question. Do you understand why two HRRZ's in a row both into A on page
 214 line 84 and 85?
 CC: me

∂21-AUG-75  0905		E,ALS
 I have looked at all of the BLT instructions and I find two where there might
 be trouble.
 page74 line 73 in OPNDEV is BLT TT,3+1(T) followed by TRNE TT,400000.
 page 95 line 46 in PURCH3 is BLT T,OBUF+17 followed by SETCM T,JOBREL.
 There are quite a few other places where there is a POPJ after a BLT and I
 have not followed these up to see where they all came from, so there could be
 trouble in one of these places. Most of them seemed reasonably safe however.
 CC: ME

∂18-AUG-75  1446		E,ALS
 I lost your message when I tried to read it!
 CC: rf

∂14-AUG-75  0807		E,ALS
 Speak to Martin Frost about CRLF's.  I told him that you would object but he
 is the one that changed things.  Maybe if you look into all that he is doing
 in this regard, you might agree that he has made some improvements.
 CC: REG

∂13-AUG-75  0942		E,ALS
 I have an experimental version of E saved as ETV[e,als] that beeps at you on the
 completion af any command that takes more than 2 seconds of real time to execute.
 What do you think of this idea? I propose to allow the user to turn the feature
 off and on and to change the reference time but to have it up at some fixed time
 for the default condition.
 CC: bh

∂13-AUG-75  0930		E,ALS
 I have an experimental version of E saved as ETV which beeps at you on the
 completion af any command that takes more than 2 seconds of real time to
 execute. If this seems like a good idea, I propose adding a feature that will
 permit one to turn the feature off or on and to change the reference time limit.
 What do you think of this idea?
 CC: ME

∂12-AUG-75  1417		E,ALS
 The order of file extensions in ETV follows. I hold no brief for this order, it
 has just grown, with some jockeying when people were unhappy.
 FAI,SAI,F4,PUB,MAC,LSP,LAP,PAL,WRU,NSA,OSA,LST,CMD,TXT,RELX,<DMPX>
 ,XGPX,DRWX,WD X,PC X,WPCX,PLTX,PCPX,PLXX,WL X,WLSX
 Don't ask me what some of them mean, they were on the list before I started
 working on ETV and I have simply added a few names as a result of pressure.
 CC: MJC

∂12-AUG-75  1335		E,ALS
 Don't you thik that the record used by BACKGLO should be appended to the data
 saved by the mark command and preserved during file switching? In particular
 one should be able to go to ? and back without losing the record of the
 earlier page.
 CC: me

∂11-AUG-75  1136		E,ALS
 I have never answered your question of 7 Aug.  The default value for the number
 of lines on a page is 33. The /F command without a /R reformatts the file to 
 the specified number of lines as a maximum on each page. If no argument is given
 this number is 33 as ETV was telling you.
 CC: REM

∂11-AUG-75  0933		E,ALS
 The parentheses matching commands in ETV are now up officially. See the write-up
 for the most recent form. I would be interested in your comments.
 CC: MFB

∂10-AUG-75  1756		E,ALS
 ME here--I recompiled and it seemed ok so I put up a new E just now.
 CC: ALS

∂10-AUG-75  1131		E,ALS
 There were several known errors in ↔ as I left it. I was only able to fix it
 up enough to compile. These have now been fixed by using your COLON routine,
 to which I have added a new label. The problems had to do with what would
 happen if the page had been altered so that the return ARRL and EDPOS were
 no longer acceptable. COLON seems to do all the right things.
 CC: ME

∂08-AUG-75  2206		E,ALS
 I have tried to send you a message several times and the system has always died. 
 I was not able to assemble until after 	 GOT HOME SO I HAVE DONE NO TESTING.THERE WEre no assembly errors however.
 CC: me

∂08-AUG-75  1659		E,ALS
 I WAS UNABLE TO GET E TO COMPILE BEFORE THE SYSTEM WAS SCHEDULED TO GO DOWN
 CC: ME

∂08-AUG-75  1030		E,ALS
 I would like to talk with you about ( ).
 CC: rf

∂07-AUG-75  1523		E,ALS
 A new set of parenthesis matching commands is up on ETV with explanation on E.ALS
 [UP,DOC] (?). I would be interested in your comments and in any bugs that you can
 find before I announce it generally. Explanation on page 22 will be shortened and
 made more precise as soon as I have some reaction from users.	ALS
 CC: MFB

∂05-AUG-75  0915		E,ALS
 RF has called attention to the fact that we have not fixed the case where one had
 previously made a correction so that the W was up and then entered but did not
 change the first line on the page. In this case the D flag is set needlessly. Do
 you think that this is important enough to need fixing? It would be relatively
 easy to do but it would involve a bit more testing every time.
 CC: ME

∂04-AUG-75  1647		E,ALS
 ME, who was responsible for the two new commands already knows about this bug
 and is trying to do something about it. You may have a clue as to how to fix
 it easier than the way he is planning.
 CC: RF

∂02-AUG-75  1622		E,ALS
 ; and : do not work quite right on top and bottom lines.
 CC: ME

∂31-JUL-75  1553		E,ALS
 Slight error in my last message.- I did use the correct PTL7W9 PT79 command.
 CC: me

∂31-JUL-75  1542		E,ALS
 Ineed your help. The <CONTROL>D routine at DELPR1 on page 27 works but when
 I try to replace the PTWR1W etc. with MOVEI C,211↔IDPB C,D↔PT77WP PT79 I get into
 trouble with repeated use or maybe only for long lines but not the last line
 on the page. I was surprised that it worked at all since I am not sure that
 the pointer in D is still right at this time. I am afraid to put this fix up
 so the system version now goes to the next line instead of leaving you in the
 line editor. It seems to work for bothe too long lines (with the proper count now)
 and for the last line on the page.
 CC: ME

∂30-JUL-75  1423		E,ALS
 Ican not find the file you mention.
 CC: rf

∂30-JUL-75  0945		E,ALS
 The no-write-if no change fix is up. It should be possible to envoke a bug in this
 code in the following way, but I have not been able to make it happen.  Maybe you
 can.
 One has a line in the text which is identical with a second line except that
 it is longer. Example:
 THIS LINE IS A TEST LINE AND IT IS LONGER
 THIS LINE IS A TEST LINE
 One deletes the first line, and writes the text out to remove the W. Then
 without making any other changes that would reset the W, one enters the second
 line and adds to it so that it is now identical to the line that was deleted.
 If conditions are right one should be able to cause this corrected line to
 be written in the free storage space formerly occupied by the deleted line.
 When it is being written, it is checked against what is left there. Since the
 deletion only changes the identifying and linking words and not the text, the
 new text agrees with the old text and the writing of the W should be suppressed.
 It doesn't seem to work this way. Why not? Every time I try it the extended line is
 appended to the end of free storage. My suspicion is that one must have conditions
 just right with not enough space left in free storage at the end for the line
 to go there but with not enough empty space scattered around for the storage to
 be crunched for all of this to happen. Do you wnderstand it?  Anyway I decided
 that it was highly unlikely that any one would be apt to be bitten by such a bug
 so I put it up on the system. All that one could possibly lose would be the
 addition to the one line, since the W would come up if any other corrections were
 made.
 CC: ME

∂30-JUL-75  0806		E,ALS
 LES sent you a not when logged in on my account by mistake so your messaage to me
 probably should be resent to him
 
 
 mail tob
 LES sent several people notes when his console was linked to my number by mistake.
 Your note to me should be resent to him, I judge.
 CC: tob

∂29-JUL-75  1033		E,ALS
 I missed your message.
 fing rf
 CC: RF

∂26-JUL-75  1333		E,ALS
 What happened to your n system?  Also the system lied to me by
 saying that you last logged out at 16:42 yet the log on E[csp,sys]
 reports that you had changed e as late as 20:11.
 CC: BH

∂25-JUL-75  1536		E,ALS
 Through an error LES sent you a message when logged in on my number. Your message
 should be redirected to him.
 CC: dbl

∂22-JUL-75  1020		E,ALS
 You sent me some info that I do not need. Is it possible you meant to send it
 to some one else? perhaps LES.
 CC: drb

∂22-JUL-75  0849		E,ALS
 I am trying to find out why you have so much trouble with the message
 NEXT DIRECTORY POINTER INVALID --. I have examined your files ITHE3 and ITHE4
 and there does not seem to be anything much wrong with them so it must be your
 operating procedures.  Could you drop in some time and demonstrate to me what
 you do that leads to this message?	ALS
 CC: DAP

∂18-JUL-75  1526		E,ALS
 The <META><CONTROL>XFIND command does not find a searched for string if it
 starts at the very first character on a page, just as the <META><CONTROL>F
 does not find the string that starts at the very beginning of the line to
 which the cursor is pointing.  This is a known bug, but very hard to fix.
 However the <CONTROL> commands do not suffer from this defect. As to the
 ∞* command description, this was implied in the text but it has now been
 made explicit.  Thanks
 CC: ref

∂18-JUL-75  1448		E,ALS
 The main bug that causes the message that you just got has been fixed, but
 files formatted before this fix will still cause trouble. There are several
 ways to fix matters up but which is the easier to use depends very much on
 the exact status of the file. In your case there seems to be a missing
 FORM FEED, perhaps between the first and the second page. One way to fix
 matters is to delete the page markers, one by one and then rewrite them.
 Another way is to copy the entire text except for the directory by the copy
 command with (2:*) as the range and then to reformat this copy with ETV.
 I would suggest that you try to fix the matter as otherwise you may continue to
 have trouble.
 CC: DAP

∂18-JUL-75  1400		E,ALS
 See PAREN[E,ALS] for a brief description of one possible parenthesis matching
 command for ETV. Would this do most of what you would like? I would like to limit
 the number of commands, just on general principles, and make the ones I do
 introduce as general as possible.
 CC: MFB

∂18-JUL-75  1138		E,ALS
 It would be hard. By the way the bug I fixed had to do with the message
 PROCEED WITH CAUTION  THE NEXT DIRECTORY----etc.
 I think that I have found the major source of these messages and fixed it!
 Time will tell.  I am still thinking about ways to save additional data in one's
 TMPCOR region and if I do this the problem you pose will be solved.
 CC: RF

∂18-JUL-75  1032		E,ALS
 I have just loaded a new version of ETV. When convenient, exit from ETV and reenter
 to get the new version.
 CC: TOB

∂18-JUL-75  1030		E,ALS
 I have just fixed a bug in ETV. When convienent exit from ETV and re load it
 to get the new version.
 CC: TAG

∂18-JUL-75  1029		E,ALS
 I HAVE JUST FIXED A BUG IN ETV AND PUT THE NEW VERSION UP. WHEN CONVIENENT
 EXIT FROM ETV AND REENTER TO GET NEW COPY
 CC: RF

∂10-JUL-75  1006		E,ALS
 The simple way to prevent being thrown off after you have said NO to a request
 for permission to reformat and have then been asked for a new name is to type
 a new name or even the name of the unformatted file that you had typed but this
 time with a /R or with /F or with /F/R or even with a /N switch. I will, however,
 look into why a <CR> response in this case does not abort the command with out
 throwing you off. Even if you are thrown off you can still save your ∃ list if
 you type S to the system and then type an acceptable file name which will
 overwrite the file name 0 but save the rest of the list.
 CC: rem

∂10-JUL-75  0950		E,ALS
 Are you sure it was ETV? They tried to put the AMPEX disk up last night and it 
 garbaged some user directories before it was halted. Maybe you should report 
 your trouble to REG. I am, of course, not at all sure it was not ETV, but before
 getting too upset I would like to eliminate the AMPEX possibility.
 CC: rf

∂09-JUL-75  1514		E,ALS
 Your short-file bug is fixed. I had dropped a comma from an AOJ A, command
 which stored a 1 in register 0 instead of in register 1 and this means readonly
 to certain parts of the code.
 CC: rf

∂08-JUL-75  1454		E,ALS
 Can you supply me  with a copy of a file with nulls compressed that misbehaves?
 CC: rf

∂08-JUL-75  1017		E,ALS
 I have fixed ETV so that an argument in a substitution command takes precedent
 ofer bucky bits in the final termination characterhis should fix the trouble you 
 noted.
 CC: ME

∂08-JUL-75  0812		E,ALS
 The ← induced bug in ETV has been fixed.
 CC: ref

∂08-JUL-75  0808		E,ALS
 You are nearly alone in your desires as regards thee HOME command. Many people
 have asked me to remove the restriction as to readwrite status. I thought that
 coupling the change with the provision that E.ALS[UP,DOC] not be included and
 that the former status of the revisited file be preserved,- that this would
 answer most if not all objections.
 CC: RF

∂06-JUL-75  1036		E,ALS
 The 7 substitutions bug was easy to fix and is fixed. Also the previous list
 has been more or less cleared up. You had better check to be sure. The ←
 bug will take more time than I have this morning. It is real and it is bad
 so I will take care of it next.  The αFXXXαβ7<CR> response is a feature and
 not a bug since αβ7αFXXX<CR> will find the 7th occurrence.
 CC: me

∂03-JUL-75  0859		E,ALS
 This is a repeat message as my earlier one seems to have been lost
 The query in Etv was put in at REG's request to guard the unwary from foolish
 mistakes. If you keep a back-up copy od a file on another area under the same
 name (as I sometimes do) then maybe the message still serves a useful purpose.
 CC: mjc

∂27-JUN-75  0909		E,ALS
 I have a reasonable fix of the /F/R problem up as RU ETV[E,ALS]. It has the
 following bug or feature, depending on how you look at it. After a /F/R
 reference, a switch to another file and a return αβ#λ one gets back OK but
 for a return αβ#ε one loses the /F along with the /R. Maybe this is as it should
 be but one is told that the old directory is invalid when it may or may not be.
 I am thinking of putting this up on the system because it is an improvement on
 what is now up. Any suggestions?
 CC: ME

∂13-JUN-75  1103		E,ALS
 A new feature on RU ETV[E,ALS] which I will clean up if people think it is
 worth while. The line number from the page which would correespond th the
 top and bottom rows (*** or ---) appears to the left on these lines. I could
 also add the total number of lines on the page to the bottom line, making
 the XL command unnecessary.
 CC: ME

∂13-JUN-75  0811		E,ALS
 Yes, I do know the game. It's English name is, of course, MILL. It is played more
 in Scandinavia than in Germany. I once had a graduate student program this but
 he did not do a very good job (it was only a term paper project), and so I made
 no effort to save it.	ALS
 CC: jfs

∂12-JUN-75  1404		E,ALS
 I have a bone to pick with yoou about the ETV-MAIL interface. Mail tells people
 the one can switch to ETV with a M command and that XRUN will get you back.
 Unfortunately this does not work if you have switched files while in ETV. It
 seems that you will either get thrown off or ETV will go into a loop, depending
 on whether you have switched back to the original file or not. XRUN normally
 takes some text but apparently you have done something so that the return
 address is remembered. Tell me how it works.
 CC: BH

∂12-JUN-75  1006		E,ALS
 You seem to have more trouble with ETV giving warnings that NEXT DIRECTORY POINTER
 INVALID -- PROCEED WITH CAUTION than most other people. Could you perhaps give
 me a clue as to why? Perhaps it might help if you could come in to my office
 and demonstrate what you have been doing that coused the trouble. You always seem to be editing PAPER[1,MG] when it happens.
 CC: mg

∂12-JUN-75  0952		E,ALS
 I would like to delay saving file names on file switching in ETV until they
 have been successfully looked up. Unfortunately this would interfere with
 your "." saving scheme. The problem is that if one types a nonsense file name
 it now gets saved. Also if one overtypes a good name (forgetting that one
 had already saved the name the good name gets overwritten with the bad. I
 tried to fix this in a very simple way by zeroing out the name when bad but
 this has the effect that if the good name overwritten happened to be number 0
 or at any rate low on the list then the ∃ command no longer can find files
 having higher numbers. Correction, the trouble on overwriting only happens
 if the name is mostly correct an so is identified as the same but then one
 does something foolish as to wrong switches or wrong format.
 
 CC: SGK

∂12-JUN-75  0855		E,ALS
 
 
 MAIL DAV
 Correction to my message- your last command was an XCAncel to cancel the corrections
 not to switch pages as I think I said.
 CC: DAV

∂12-JUN-75  0835		E,ALS
 You got thrown off of ETV yesterday at 17:12. Can you tell me the circumstances.
 in particular was the XCANCEL command correctly executed or were you thrown off
 before this was done? It looks to me like you ran a program called PPSAV.TMP
 which did something that I have no record of, and then gave the command HOME
 bringing something in the ATTACH buffer which you then deposited. This must have
 had about 210 characters plus the amount you then deleted with a line delete
 command. Then you tried to delete a page mark and it blew. I have seen this
 particular bug only once before and this was before I had such complete
 reporting so I was unable to track it down.	ALS
 CC: DAV

∂10-JUN-75  1313		E,ALS
 It seems to work! Do you want to test it before I put it up.
 CC: ME

∂09-JUN-75  1248		E,ALS
 Iam back from lunch.
 CC: RF

∂09-JUN-75  1038		E,ALS
 You might look in to the new file switches as one means of avoiding trouble
 with invalid directory pointers. Type <CONTROL>? when in ETV and see page 21.
 CC: BES

∂09-JUN-75  0833		E,ALS
 I am trying to work on your bug and I simply can not make it happen. There must
 be something different about the way I try to do it from the way you do. Would you
 like to come in and demonstrate again. PDQ has reported the same kind of bug so 
 I think that there is one for sure but unless I can reproduce it I have very little
 chance of fixing it. In case this does not ring bells I am talking about the 
 SOS bug with file GEYEG.YID[MAP,RF).
 CC: RF

∂06-JUN-75  1332		E,ALS
 more- I can help matters some if when I write ZDATA from the EDFIL locations I check
 for the /f only case and overwrite the appropiate cell where EDFIL-2 gets written
 with zero. This may still not be enough however since I do not save the /R flag
 and so one could read a file with /F/R, switch then come back with a numbered ε
 whereupon it would have remembered the /F. Oh me!
 CC: me

∂06-JUN-75  1326		E,ALS
 I am back. If, as you say TMPCOR remembers the string then your explanation may
 not be complete since I do not set up the /N actually but only set the flag
 word that the /N would set. However the tempcor must be written before the
 code for /F is executed while Edfil-2 is still set up and before it has been
 put back to zero, so that whether TMPCOR gets the data from the ASCII string or
 from the flag word it is still wrong for the /F only case.
 CC: me

∂06-JUN-75  0857		E,ALS
 Try reading the file CPU.WL[282,LCH] WITH THE SWITCHES /F/R, that is type
 ET CPU.WL/F/R and you may be able to read the file without trouble. It seems that
 this file is not properly formatted for use with ETV.
 CC: LCW

∂06-JUN-75  0848		E,ALS
 Can you tell me what caused the trouble just now?
 CC: lcw

∂05-JUN-75  2232		E,ALS
 I put the message in twice just to mage sure that it was seen.
 I had expected the /R mode not to say anything about keeping
 the directory. There is a problem in that the same bit of code is
 used for several purposes and it is getting so laden with conditional
 tests for the several options that I am having trouble keeping every
 thing straight.  Maybe we should look at the SOS case togaather.
 CC: rf

∂05-JUN-75  1619		E,ALS
 YOU MIGHT LIKE TO TRY MY NEW VERSION RU ETV[E,ALS] which has a new switch
 /F or /F/R which limit the number of lines on a page to a default value of 33.
 /52F sets the line count to 52 etc. /F alone reformats your file while /F/R
 puts pseudo page marks in your core version only without affecting the disk
 copy. This should be useful for reading long files.
 CC: bpm

∂05-JUN-75  1612		E,ALS
 You might like to try RU ETV on E,ALS. I haven't tried it on SOS files but it may
 be that your bug has gone away. If it has not that will be the next item on my
 list. The new commands or rather switches are /F/R which repages readonly to a
 default page length of 33 lines, and /F alone which reformats the file with a 
 maximum line length of 33 words. In both cases the old page marks are still
 respected as well. /52F is the way to specify 52 lines etc.
 CC: rf

∂05-JUN-75  1056		E,ALS
 That is bad news for sure since it used to not do this. I will have to look into it.
 
 CC: RF

∂05-JUN-75  1054		E,ALS
 DO YOU MEAN WITH THE SYSTEM VERSION OF ETV?
 CC: RF

∂05-JUN-75  0812		E,ALS
 I have found an easy way to increase the allowable number of pages to any desired
 number as long as one is willing to forgo the use of MARKS on pages with higher
 than 511 number. I hather hate to do this however since it might encourage people
 to make and use very large files which will bother them more than others but
 which is still not a good idea. I am inclined to leave the limit where it is altho
 it would do no harm to increase it to 510 (reserving 511 for an existing function)
 
 CC: JFR

∂04-JUN-75  1340		E,ALS
 ETV was not designed to handle lines with more than 511 characters, ges with
 more than 511 lines and files with more than 511 pages. It keeps such numbers
 frequently in 9-bit bytes and it is a major undertaking to redo everything
 that is so dependent. I hate to think of the complications since this technique
 is so intertwined with the entire program. Why do you keep such a file in one
 piece? When I have delt with big files I have always found it desirable to
 break them into smaller pieces. It speeds up editing, and for progrrams makes
 recompiling much faster since one need only redo affected portions, etc.
 CC: Jfr

∂04-JUN-75  1153		E,ALS
 Second installment
 I now have another version which never complains on /F but will not save the 
 new directory after a /F, in fact both directories are gone with a write out.
 CC: ME

∂04-JUN-75  1001		E,ALS
 It's partially fixed. It always keeps the old directory as a part of the text,
 telling you that it is doing this. It allows a change from readonly to
 readwrite but may get into trouble over this because of the old directory and
 because it has not saved the new paging before.
 CC: ME

∂04-JUN-75  0805		E,ALS
 I KNOW! It is not quite ready for public consumption.
 CC: rf

∂02-JUN-75  0913		E,ALS
 Can you come in to talk about the SOS problem? I am in the middle of fixing
 ETV so thaat there will be a /F mode which will allow one to page a /R file
 to any desired page size for convenience in reading it and this is a good time
 for me to fix your problem as well.
 CC: rf

∂02-JUN-75  0852		E,ALS
 Most things now work for /F. I am thinking about the following:
 1) Fix it so the default value for a /F value is set to 511 automatically when
 one types /R only. Since the line count is or will be set to zero every time a
 true FF is found, this would do nothing to files that are already paged to smaller
 limits.
 2) Test files that are to be formatted to see if they are paged already to less
 than 511 lines and if not to ask if this should be done. This request could be
 introduced during the directory making process and it would add very little to
 the running time if the pages were all shorter than this limit.
 3) Perhaps reverse the situation and fix it so that pages are always limited in
 size unless the user specifically requests otherwise.
 CC: ME

∂01-JUN-75  1813		E,ALS
 When you get the directory pointer invalid message it is wise to stop
 and fix things up. Unless you are in the readonly mode you can do this
 by the CONTROL . command. If it still complains then it is wise to
 leave ETV and reload the offending file. I am at home so I cannot
 look into your trouble very well at the moment but I have gotten a whole
 string of error messages which would indicate that you continued to 
 do what ever it was that led to the message many times, or that ETV was in a loop
 that you did not intercept.
 CC: BPM

∂01-JUN-75  1750		E,ALS
 Sorry I was not more specific.
 Mainly I fixwd up the matter of asking about formatting when one had
 typed /F. It seems to me that it should not be necessary to ask
 if it is OK to format when one has typed /F. So now it does not ask
 unless the file seems to be a binary file or if it is from a different
 PPN area than that of the person logged in. I also do not see the reason
 why one still has to store the /F value in FFLINE AND LATER TRANSFER IT TO
 EDFIL-2 so I fixwded it to store both places at once. THE
 remaining bad bug is that `fter one has done a /F/R and then tries to
 go back home with a H command the system still remembers and
 thinks that the home file is /F. I kept a copy of E as you left it as e.41
 so if you want to undo all of this it will be very easy.
 CC: me

∂01-JUN-75  1348		E,ALS
 Did you retype the UDP1: over again the second time/∨? If you did not
 this could be the trouble but probably you did and there is a bug. I
 have another related bug which may be due to the same thing. I will
 look into it on Monday.
 CC: jam

∂01-JUN-75  1134		E,ALS
 I fixed a few minor bugs but one remains that is very bad. This has to do with
 switching. I thought that if we stored /F in edfil-2 at once on page 63 some of
 these troubles would go away but they did not so I do not understand it correctly.
 This fix is now in however. I will not be able to work much till monday so
 good luck.
 CC: ME

∂31-MAY-75  0821		E,ALS
 That is not all that has to be fixed to make E work for the /F/R case. Suppose
 that you enter a file in this way, put some marks on page 1 then go to some other
 page, say 3. E will  copy through to page three ok but no record will be kept as
 to where in the specified records page 2 and page 3 start.
 Now you go back to page 2. Will E have to start all over and read from page 1
 to find the start of page 2? Now you decide to make some additions or deletions
 to page 2, giving the readwrite command  so that these will be accepted and thy to
 go back to your marks on page 3. What will happen? The straight forward way would
 be to redo the directory completely but this will mess up your marks. I hav figured
 how one might make a modification to the directory for the /F/R case to keep an
 additional number in addition to the record number to hold the line offset so that
 E does not have to start all over each time and this should be fairly simple as
 long as you do not make any changes to earlier pages but it would be very messy to
 change everything and create a new directory while taking proper care of marks.
 I am thinking about this but I think that I will ignore the readwrite change
 problem until I get the simple case working.
 CC: ME

∂31-MAY-75  0809		E,ALS
 What did you mean telling Taylor that ETV will not now handle SOS files? This
 is news to me. I thought that my fix worked OK. The only thing different should
 be that it tells you that you are trying to format an SOS file and requires
 confirmation that that is what you in fact want to do.	ALS
 CC: RF

∂30-MAY-75  1710		E,ALS
 RG is wrong. You can use ETV with SOS files. It does now tell you that
 you are working on an SOS file but if you tell it to cggo Ahread it does
 the right thhngs. It may be that some troubles might occur if you try to
 use ETV over the net. I do not know about thids.  I will get RF to explain
 his objections. 
 CC: RHT

∂30-MAY-75  1131		E,ALS
 I fixed the bug in /F and am a fair way along on the /R case. This gets a bit
 hairy if one lets the directory be created incrementally. The trouble is that
 the convenient time to introduce the FF seems to depend upon too many factors.
 I am sure that when I have thought it trrough properly I will find a better way
 than I now see how to do it. The code will definitely have to go somewhere near
 where we first put the /F stuff but certainly not exactly there.
 CC: ME

∂29-MAY-75  0946		E,ALS
 We were trying to do too much with too little. I am beginning to see what we
 need to do. We must differentiate between three different cases, that is
 1) /F switch only
 	Format the file with a FF and a new record and new page after every
 	FFLINE number of lines, create and save the new directory.
 2)/F and /N switches both used
 	Same as case 1) above except that the directory is creaated on page 0
 	and is not written out. The file will be rippled and padded out so that
 	the FF's are at the beginning of new records.
 3) /F and /N switches both used
 3) /F and /R switches both used
 	In this case we do not want to ripple the file so a pseudo directory
 is created on page 0 and a record should somehow be kept of the line count
 	at the start of each block so that ETV will not have to read from
 	the beginning every time a new page is switched to.
 One might expect a fourth case when /N, /R and /N are all three given, but
 in this case the /R would take precedence and the /N would simple be ignored.
 
 In case 1) the FFline value would not be written into EDFIL-2, since the value
 would be used only on the first formatting and it would not want to be
 remembered on file switching. This would also apply to case 2).
 in case 3) we would want to save the FFLINE value so that when the file is
 recalled by number we would recall the value and the same pseudo directory
 would be recreated.
 CC: ME
This is a file to save outgoing mail.